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Abstract.  The  slow  adoption  of  agent-oriented  methodologies  as  a  paradigm  for 
developing  industry  systems  is  due  in  part  to  their  lack  of  integration  and  general- 
purpose  use.  There  exists  a  need  to  define  common  patterns,  relationships  be¬ 
tween  components,  and  structural  qualities  that  a  reference  architecture  for  agent- 
based  systems  would  solve.  However,  there  is  little,  if  any,  consensus  on  how  to 
create  a  reference  architecture  for  agent-based  systems.  This  paper  presents  a 
methodology  for  developing  a  reference  architecture  that  documents  agent-based 
systems  from  different  system  viewpoints.  Rather  than  the  traditional  approach 
of  studying  existing  systems,  the  documentation  methodology  relies  on  forensic 
software  analysis  of  agent  frameworks  (i.e.,  APIs  and  libraries  for  constructing 
agent  systems).  We  demonstrate  the  methodology  by  describing  the  process  used 
to  create  the  Agent  System  Reference  Architecture. 

1  Introduction 

Using  agent-based  approaches  for  constructing  large  complex  distributed  systems  can 
provide  advantages  over  traditional  methods  [5],  Unfortunately,  industry  has  been  slow 
to  adopt  this  agent-oriented  paradigm.  One  reason  for  this  slow  adoption  is  the  lack  of 
integration  and  general-purpose  technologies  [13].  Standards  bodies  such  as  the  Foun¬ 
dation  for  Intelligent  Physical  Agents  (FIPA)3  are  leading  efforts  to  standardize  pro¬ 
tocols  and  formats  of  an  agent-based  system.  However,  there  is  a  need  to  construct 
a  reference  architecture  that  defines  the  relationships  between  standardized  terms  and 
concepts  of  an  agent-based  system.  Furthermore,  such  an  architecture  would  give  a  set 
of  architectural  blueprints  and  best  practices  to  aid  in  developing  new  agent  frameworks 
and  systems.  To  this  end,  a  reference  architecture  for  agent -based  systems  would  speed 
other  standardization  efforts  and  adoption  as  a  viable  systems  engineering  perspective. 

This  paper  describes  a  documentation  methodology  for  creating  the  Agent  Systems 
Reference  Architecture  (ASRA)  for  agent  frameworks.  Rather  than  studying  agent  sys¬ 
tems  across  unrelated  application  domains,  this  work  studies  the  agent  frameworks  used 
to  construct  software  systems  composed  of  agents.  The  ASRA  builds  upon  the  Agent 
Systems  Reference  Model  (ASRM)  [11]  by  identifying  and  documenting  the  interac¬ 
tions  between  ASRM  functional  concepts  typically  found  in  an  agent  system. 

3  http : // www . f ipa . org 
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Our  approach  to  creating  the  ASRA  for  agent  frameworks  combines  static  and 
dynamic  software  analysis  tools  with  a  regimented  documenting  process  4+1  View 
Model  [6]  to  existing  agent  framework  implementations  creating  five  architectural  views. 
The  process  for  creating  the  ASRA  is  as  follows: 

1.  For  every  ASRM  functional  concept,  the  ASRM  definiton  of  each  functional  con¬ 
cept  comprises  the  Scenario  view  of  the  4+1  Model. 

2.  For  each  agent  framework  implementation  under  analysis,  implement  a  basic  ap¬ 
plication  that  exercises  the  functional  concept.  Execute  this  application  within  an 
application  profiler  to  generate  runtime  data  to  build  the  Process  view. 

3.  Perform  static  analysis  on  the  source  code  of  the  agent  system  functional  concept 
to  build  the  Implementation  view. 

4.  Finally,  abstract  the  package  decompositions  into  the  Logical  view. 

The  main  contribution  of  this  paper  is  a  novel  methodology  for  creating  reference 
architectures  for  a  class  of  systems  based  on  a  domain  reference  model.  Previous  ap¬ 
proaches  rely  on  studying  classes  of  existing  systems  and  constructing  reference  archi¬ 
tecture  documents.  Moreover,  we  believe  this  methodology  is  general  enough  to  apply 
to  other  software  system  domains. 

The  rest  of  this  paper  is  organized  as  follows:  Section  2  defines  the  terms  archi¬ 
tecture ,  reference  architecture  in  the  context  of  agent  systems  and  agent  frameworks. 
Section  2.2  describes  the  Agent  Systems  Reference  Model  and  its  basis  for  creating  the 
ASRA.  Section  3  provides  a  description  of  the  4+1  Model  and  how  it  will  be  applied 
to  agent  frameworks  followed  by  an  application  of  the  process  to  create  a  portion  of 
the  ASRA  in  Section  4.  Section  5  provides  a  summary  of  related  efforts  in  reference 
architectures  for  agent-based  systems.  Finally,  we  conclude  with  related  efforts  and  a 
roadmap  of  this  continuing  work  for  developing  a  reference  architecture  for  agent  sys¬ 
tems. 

2  Background 

This  section  defines  a  reference  model  and  a  reference  architecture.  We  use  these  defi¬ 
nitions  to  further  define  a  reference  architecture  for  agent  systems. 

2.1  What  is  a  Reference  Model  and  Architecture? 

A  reference  model  describes  the  abstract  functional  elements  of  a  system.  A  refer¬ 
ence  model  does  not  impose  specific  design  decisions.  APIs,  protocols,  encodings,  and 
other  standards  are  not  included  within  a  reference  model,  but  can  be  use  concurrently. 
A  reference  model  does  not  explicitly  define  an  architecture,  but  rather  can  drive  the 
implementation  of  multiple  architectures.  The  novelty  of  a  reference  model  is  that  it 
provides  a  common  ontology,  innovative  and  practical  system  engineering  techniques, 
and  software  development  guidance  [11], 

A  software  architecture  is  an  abstract  representation  of  a  software  system.  It  is  com¬ 
posed  of  structures  and  components  of  the  system,  their  properties,  and  the  relation¬ 
ships  between  them  [2],  A  reference  architecture  has  many  definitions,  but  the  most 


commonly  used  in  the  software  engineering  literature  is  that  a  reference  architecture 
consists  of  standardized  diagrams  ( e.g .,  UML,  ADL,  etc.)  that  describe  the  architecture 
from  different  viewpoints  to  cover  the  concerns  of  the  stakeholders  of  a  system.  These 
standardized  diagrams  are  used  to  abstract  the  implementation  details  of  a  system  and 
illustrate  the  relationships  between  the  components  of  a  system  [14], 


2.2  A  Reference  Model  for  Agent  Systems 


The  basis  for  the  ASRA  is  the  Agent  Systems  Reference  Model  (ASRM)  [11].  The 
ASRM  provides  a  model  for  software  systems  composed  of  agents.  It  establishes  terms, 
concepts,  and  definitions  required  to  compare  agent  systems. 

The  ASRM  defines  an  intelligent 
agent — or  simply  agent — as  situated 
computational  processes  that  embody 
one  or  more  of  the  following  quali¬ 
ties:  autonomy,  proactivity,  interactiv¬ 
ity,  continuous,  sociality,  and/or  mobil¬ 
ity.  The  ASRM  also  formalizes  con¬ 
cepts  and  layers  of  organization  in  an 
agent-based  system.  The  layers  (shown 
in  Figure  1)  are:  agents,  frameworks, 
platforms,  hosts,  and  environments.  An 
agent-based  system  is  the  set  of  frame¬ 
works,  the  agents  that  execute  in  them, 
the  platform  (other  software)  that  sup¬ 
ports  them  and  the  hosts  (hardware)  upon 
which  they  execute. 

The  ASRM  describes  an  agent  sys¬ 
tem  as  a  set  of  abstract  functional  con¬ 
cepts  that  support  overall  system  execu¬ 
tion.  The  functional  concepts  represent 
the  complex  interactions  between  soft¬ 
ware  and  hardware  located  at  different  layers  of  the  agent  system.  The  functional  con¬ 
cepts  are  as  follows: 


Fig.  1.  Anatomy  of  an  agent  and  its  role  in  an 
agent  system. 


-  Agent  Administration  facilitates  and  enables  command  and  control  of  agents  and 
allocates  resources  to  those  agents  as  needed. 

-  Security  and  Survivability  prevents  execution  of  undesirable  actions  within  an 
agent  system  while  allowing  execution  of  desirable  actions. 

-  Mobility  facilitates  and  enables  the  migration  of  agents  among  framework  in¬ 
stances  (typically,  but  not  necessarily,  on  different  hosts) 

-  Conflict  Management  facilitates  and  enables  the  management  of  interdependen¬ 
cies  between  agents  activities  and  decisions. 

-  Messaging  facilitates  and  enables  information  and  data  transfer  among  agents  in 
the  system. 


-  Logging  facilitates  and  enables  information  about  events  to  be  recorded  occurring 
during  system  execution  for  subsequent  inspection. 

-  Directory  Services  facilitates  and  enables  the  locating  and  accessing  of  shared 
resources. 

The  functional  concepts  are  necessary  in  developing  the  ASRA  as  they  are  the  start¬ 
ing  point  for  the  analysis  process. 


2.3  The  Agent  Systems  Reference  Architecture 

The  Agent  Systems  Reference  Architecture  (ASRA)  is  an  elaboration  of  the  ASRM.  It 
establishes  relationships  between  the  ASRM  functional  concepts  in  agent  frameworks 
and  defines  patterns  for  these  concepts.  The  ASRA  does  not  address  implementation 
specifics  but  rather  describes  possible  interactions  between  functional  concepts.  A  ref¬ 
erence  architecture  for  agent  systems  can  be  defined  from  the  standpoint  of  the  indi¬ 
vidual  agent  functionality,  the  agent  framework,  the  group  and  agent  societies,  or  the 
system-to-system  interaction  viewpoints.  In  this  work,  we  focus  on  the  agent  frame¬ 
works  because  the  functional  concepts  defined  in  the  ASRM  are  largely  implemented 
in  these  frameworks. 


3  Serial  Approach  to  Constructing  the  ASRA 

We  construct  the  ASRA  by  applying  reverse  engineering  methods  on  sample  applica¬ 
tions  built  using  existing  open  source  agent  frameworks.  We  systematically  build  mul¬ 
tiple  view  models  by  analyzing  popular  agent  framework  implementations:  JADE4, 
Cougaar5  and  AGLOBE6.  These  agent  frameworks  were  chosen  for  analysis  because 
of  their  popularity  in  the  agent  system  community  and  the  availability  of  their  source 
code  and  documentation. 

Agent  systems  have  a  broad  definition  and  have  many  applicable  domains,  study¬ 
ing  a  particular  fielded  system  or  class  of  systems  may  not  cover  all  the  architectural 
variations  of  a  reference  architecture.  Therefore,  we  study  agent  frameworks  rather  than 
fielded  systems  or  specific  domains.  This  approach  avoids  the  endless  debate  of  the  ex¬ 
act  definition  of  an  agent  and  intelligence  and  simply  addresses  the  systems  composed 
of  agents. 


Adapting  the  Rational/4+1  View  Model:  The  Rational/4+1  View  Model  [6, 7]  creates 
different  architectural  descriptions,  or  views,  of  software  systems  for  different  interested 
parties  ( e.g .  system  developers,  business-persons,  customers).  Each  view  identifies  and 
describes  the  relationships  between  components  and  concepts.  Interested  parties  will 
view  these  relationships  with  different  weights  and  significance.  The  views  in  the  4+1 
Model  are  as  follows: 

4  http : //jade . tilab . com 

5  http : // www . cougaar . org 

6  http : //agents . f elk . cvut . cz/ aglobe 


-  The  Logical  View  describes  the  static  structural  layout  of  the  software  system  from 
the  perspective  of  a  software  developer. 

-  The  Process  View  describes  the  runtime  behavior  of  the  system,  including  concur¬ 
rency  relationships  and  ordered  tasks  carried  out  by  components  of  the  system  from 
the  perspective  of  a  workflow  designer  or  manager. 

-  The  Implementation  View  describes  the  package  layout  of  the  system  from  the 
perspective  of  the  system  architect. 

-  Deployment  View  describes  the  hardware-software  configurations  at  a  platform- 
level  as  viewed  by  system  administrators  or  deployment  teams. 

-  Scenario  View  is  the  “+1”  view  that  spans  the  other  four  views.  This  crosscutting 
view  is  composed  of  narrative  use  cases  to  provide  an  executive  level  view  of  the 
architecture. 

The  ASRA  is  documented  using  the  Scenario,  Process,  Logical,  and  Implementa¬ 
tion  Views.  Each  ASRM  functional  concept  is  documented  with  these  four  views  to 
cover  the  needs  of  agent  system  architects,  developers,  agent  framework  designers,  and 
system  users.  The  ASRA  does  not  present  the  Deployment  view  because  this  view  ad¬ 
dresses  the  needs  for  system  administrators  and  deployment  teams. 


The  Serial  Approach:  The  goal  of  the  serial  approach  is  to  produce  overlapping  series 
of  documents  and  diagrams  detailing  many  views  of  a  system  from  different  perspec¬ 
tives.  We  document  the  most  abstract  views  first  and  augment  each  with  software  anal¬ 
ysis  data  and  domain  knowledge  to  create  the  next  view.  We  mine  for  software  archi¬ 
tecture  data  by  performing  static  and  dynamic  analysis  of  multi-agent  frameworks  [10]. 

For  each  functional  concept  defined  in  the  ASRM  apply  the  following  process: 

1.  Construct  the  Scenario  View  for  a  functional  concept.  The  scenario  view  consists 
of  functional  concept  definitions  from  the  ASRM  including  possible  interactions 
with  other  functional  concepts.  The  scenario  view  for  each  functional  concept  con¬ 
sists  of  UML  use-case  diagrams  and/or  descriptions  depicting  the  use,  role,  and 
functionality  of  the  concept. 

2.  Construct  the  Process  View  from  the  Scenario  View.  We  implement  a  snippet  of 
code  exercising  the  functional  concept  for  each  agent  framework.  Execute  this  snip¬ 
pet  of  code  and  use  the  dynamic  runtime  analysis  framework.  Enterprise  Java  Pro¬ 
filer  (EJP)7,  to  generate  trace  data.  With  this  trace  data,  construct  a  UML  process 
diagram  to  illustrate  a  concrete  architecture  for  the  functional  concept  for  a  partic¬ 
ular  agent  framework.  After  constructing  process  diagrams  for  each  agent  frame¬ 
work,  create  a  new  process  diagram  from  the  common  features  across  the  agent 
framework  implementations  while  documenting  differences  as  points  of  variation. 
This  abstract  architecture  for  the  functional  concept  and  the  points  for  variation 
comprise  the  Process  View. 

3.  Construct  the  Implementation  View  using  the  static  analysis  tools,  BAT  [4]  to  iden¬ 
tify  data  flow  and  package/class  dependencies  of  each  functional  concept.  We  use 

7  http : //e jp . sourcef orge . net 


these  software  tools  on  the  agent  frameworks  and  code  snippets  from  Step  2.  Fo¬ 
cusing  on  the  code  snippets  allows  us  to  bypass  extraneous  information  such  as 
dead  code  and  common  library  dependencies.  We  construct  a  UML  component  di¬ 
agram  for  each  agent  framework.  Components  represent  the  modules  and  packages 
and  connectors  represent  interdependencies.  Next  we  construct  an  abstract  architec¬ 
tural  package  representation  by  identifying  similar  packages  and  modules  from  the 
concrete  architectures.  Different  packages  are  documented  as  points  of  variabilion. 

4.  Construct  the  Logical  View  using  the  Bunch  clustering  system  [9]  and  the  static 
analysis  data  from  the  previous  step.  The  Logical  View  consists  of  UML  pack¬ 
age  diagrams  of  a  functional  concept.  This  abstract  architectural  representation  of 
a  functional  concept  is  created  from  the  concrete  architectural  views  of  the  agent 
frameworks.  The  clustered  data,  represented  as  a  graph,  illustrates  interdependen¬ 
cies  between  components  (edges)  and  modules  (nodes)  within  the  agent  framework 
implementation.  Highly  connected  modules  indicate  components  and  subsystems 
within  an  agent  framework  implementation.  UML  package  diagrams  depict  the  the 
concrete  logical  architecture  of  each  agent  framework  implementation  where  pack¬ 
ages  are  the  modules  and  the  connectors  are  interdependencies.  Packages  within 
other  packages  represent  interdependencies  that  do  not  travel  outside  the  enclosing 
package.  From  the  concrete  logical  architectures  of  the  agent  framworks,  we  create 
an  abstraction  noting  similarities  and  differences.  The  differences  are  documented 
as  points  of  variation. 

The  result  yields  the  agent  systems  reference  architecture  consisting  of  four  docu¬ 
ments  for  each  ASRM  functional  concept. 


4  Application  of  the  Serial  Approach 

To  demonstrate  the  serial  approach,  we  step  through  the  documentation  process  for 
the  mobility  functional  concept  by  analyzing  agent  framework  implementations:  Jade, 
AGLOBE,  and  Cougaar. 


4.1  The  Scenario  View  for  Agent  Mobility 

The  Scenario  View  of  the  ASRA,  based  on  the  4+1  View  Model,  contains  scenarios  and 
use  cases  of  a  system’s  architecturally  significant  behavior. 


Mobility  Debnition:  Mobility  is  the  process  by  which  an  agent  migrates  from  one 
executing  platform  instance  to  another.  The  functional  concept  use  cases  (ellipses)  are 
depicted  in  a  UML  use-case  diagram  (Fig.  2).  The  move  agent  (moving  an  agent  from 
one  container  to  another)  and  the  clone  agent  (making  a  copy  of  an  agent  in  another 
container)  use  cases  are  invoked  by  the  container  (represented  by  an  actor).  Note,  this 
figure  also  illustrates  interactions  between  the  Agent  Administration  and  Directory  Ser¬ 
vices  functional  concepts.  For  example,  the  clone  agent  use  case  uses  the  create  agent, 
modify  agent  state  use  case. 


Fig.  2.  The  Mobility  functional  concept  use  case  diagram  and  the  interactions  with  the  Agent 
Administration  and  Directory  Services  functional  concept. 


4.2  The  Process  View  for  Agent  Mobility 

The  Process  view  documents  the  runtime  behavior  of  a  functional  concept  based  on  a 
code  snippets  for  each  agent  framework.  Executing  EJP  on  code  snippets  yield  runtime 
traces.  The  runtime  trace  illustrates  the  percentage  of  time  spent  in  methods  during  ex¬ 
ecution.  The  runtime  trace  (Fig.  3(a))  shows  a  temporal  view  of  the  mobility  functional 
concept  and  illustrates  the  invocation  points  of  the  agent  mobility  functional  concept. 
From  the  runtime  trace,  we  create  a  UML  activity  diagram  (Fig.  3(b)). 

Mobility  Process  View  Patterns:  We  repeat  this  process  for  AGLOBE  and  Cougaar 
to  construct  similar  Process  diagrams.  Comparing  the  diagrams,  two  patterns  for  agent 
mobility  emerge.  Jade  and  AGLOBE  exhibit  Serialization  mobility  (Fig.  3(c))  in  which 
an  agent’s  execution  is  paused,  converted  into  a  transferable  form,  transmitted  to  a  target 
platform,  converted  into  an  executable  form,  and  resuming  agent’s  execution.  Cougaar 
exhibits  shared-object  mobility  in  which  agents  are  shared  between  platform  containers 
and  the  agent’s  state  is  synchronized  across  platforms  during  execution.  Agent  mobility 
is  achieved  by  changing  the  shared  state  to  the  new  platform  location. 

4.3  The  Implementation  View  for  Agent  Mobility 

The  Implementation  view  is  the  static  view  of  the  agent  system  derived  through  static 
code  analysis  tools  and  temporal  data  from  the  process  view.  UML  component  diagrams 
depict  the  high-level  components  of  a  functional  concept  and  their  interactions  with 
other  components  and  functional  concepts. 

Mobility  Implementation  View  Patterns:  The  two  patterns  for  Mobility  from  the 
Implementation  view  (Fig.  4):  serialization  mobility  and  ticketing  mobility. 


▼  100.0%  <root>  (28.00  s) 

▼  100.0%  jade.core.Agent.run(..,)  (28.00  s) 

▼  73.5%  jade. core.Agent$ActiveLifeCycle.execute(...)  (20.00  s) 

▼73.5%  jade.core.behaviours.Behaviour.actionWrapper(...)  (20.00  s) 

▼  73.4%  WhereaboutsAgent$2.action(...)  (20.00  s) 

^  64.7%  jade.domain.AMSService.search(...)  (18  00  s) 

►  64.5%  jadP  domain  AMSRervIra  searchf...)  (18.00  s) 

►C01%  jade.core.Agent.getAMS(-)  (40,00  msLH> 

▼  8.5%  WhereaboutsAgent.moveMyself(...)  (2.00  s) 

^  5.7%  jade.content.ContentManager.extractContent(...)  (1.00  s) 

▼  2.3%  WhereaboutsAgent.sendRequest(...)  (670.00  ms) 

►  2.1%  iade.content.ContentManager.fillContentt...)  (590.00  ms) 
dTO.3%  jade.core.Agent.send(...)  (80.00  ms) 

►  0.2%jade.core.Agent.gelAMS(...)  (60.00  ms) 

►  0.1%  iade. core  .Agent,  blocking  Receive!...!  (20.00  ms) 

jade.core.Agent.doMove(...)  (20,00 
|C5!0%  jade.core.Agent.getName(...)  (10.00  msT^> 

►  19.4%  jade.core.mobility.AgentMobilityService$TransitLifeCycle.execute(...)  (5,00  s) 
^  7.1%  jade.core.AgentActiveLifeCycle.init(...)  (2.00  s) 

(a)  Runtime  Trace  for  Jade  Mobility. 


(b)  Activity  Diagram  for  Jade  Mobility. 
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(c)  Mobility  Process  View:  Serialization  Pattern. 


Fig.  3.  Jade  Mobility  runtime  trace  and  resulting  concrete  architecture  Process  view  diagram. 
Comparing  architecture  diagrams  for  each  agent  framework  leads  to  an  abstract  architecture  for 
the  mobility  functional  concept. 


Jade  and  AGLOBE  mobility  follow  a  serialization  mobility  pattern  (Fig.  4(a)).  The 
Platform  Discovery  component  uses  Directory  Services  to  find  the  destination  platform. 
The  Agent  Encapsulation  component  creates  a  representation  of  the  mobile  agent  for 
transport.  The  Messaging  component  delivers  the  mobile  agent  to  the  destination  plat¬ 
form.  Finally,  the  Agent  Extraction  component  receives  the  mobile  agent,  loads  it  in  the 
platform,  and  resumes  its  execution. 

Cougaar  mobility  follows  a  ticketing  system  pattern  (Fig.  4(b)).  The  Platform  Dis¬ 
covery  component  uses  the  Directory  Services  component  to  find  the  destination  plat¬ 
form.  A  Mobility  Factory  component  generates  a  ticket  ID  to  identify  the  destination 
platform  of  the  mobile  agent.  Finally,  the  Mobile  Agent  component  uses  messaging 
functional  concept  to  publish  the  ticket  to  the  other  hosts. 

4.4  The  Logical  View  for  Agent  Mobility 

The  Logical  Views  express  the  high  level  packages  and  interacting  components  existing 
in  an  agent  system.  The  Logical  View  is  constructed  by  observing  the  clustered  runtime 
data  generated  from  EJP  and  BAT  and  organizing  the  major  objects  into  packages.  This 
organization  is  represented  with  UML  package  diagrams. 


Mobility  Logical  View  Patterns:  The  Logical  view  for  Mobility  depicts  two  patterns: 
Serialization  Mobility  and  Shared  Object  Mobility. 

Jade  and  AGLOBE  follow  the  serialization  pattern  in  which  the  agent  is  converted 
to  a  transferable  form  before  migrating  the  agent  to  its  destination.  The  Mobility  func¬ 
tionality  (Fig.  5(a))  depends  on  the  agent  administration  to  pause  and  start  the  agent  and 
messaging  components  to  transmit  the  agent. 

Cougaar  follows  the  shared  object  mobility  pattern  in  which  the  agent  representa¬ 
tion  is  shared  among  platforms.  Agent  mobility  involves  synchronizing  the  state  of  the 
agent  then  halting  the  agent  on  the  source  platform  and  initializing  and  executing  the 
agent  on  the  target  instance.  Shared  object  mobility  (Fig.  5(b))  depends  on  the  agent 
administration  component  for  halting  and  initializing  the  agents,  the  messaging  compo¬ 
nent  for  synchronizing  the  state,  and  directory  services  for  finding  the  target  platform. 


5  Related  Work 

In  developing  the  methodology  for  creating  the  ASRA,  we  studied  two  related  areas 
of  research:  approaches  and  methodologies  for  creating  a  reference  architecture,  and 
reference  architecture  related  to  agent-based  systems. 

The  multiple  view  presentation  for  the  ASRA  is  adopted  from  the  ISO/IEEE147 1  [  1  ] 
recommendation  for  architecture  documentation.  Another  example  of  presenting  a  ref¬ 
erence  architecture  in  multiple  views  is  the  Reference  Architecture  Foundation  for  Ser¬ 
vice  Oriented  Architectures  (RAF-SOA)  [8]  from  the  OASIS  foundation.  The  RAF- 
SOA  presents  a  reference  architecture  for  SOA  systems.  Moreover,  similar  to  the  ASRA, 
the  RAF-SOA  is  based  on  the  definitions,  layered  OASIS  reference  model  for  service 
oriented  architectures. 


(a)  UML  Component  di-  (b)  UML  Component  diagram  for  ticketing  mobility 

agram  for  serialization 

mobility 


Fig.  4.  Implementation  View:  Two  Patterns  for  Mobility. 
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(a)  Serialization  paradigm:  The  migra- 
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(b)  Shared  Object  paradigm:  The  mi 
gration  component  depends  on  the  di¬ 
rectory  services  component,  the  agent 
controller  component,  and  the  messag¬ 
ing  component. 


Fig.  5.  The  Logical  View:  two  paradigms  for  Mobility. 


The  process  for  creating  a  reference  architecture  for  systems  in  a  regimented  manner 
is  often  addressed  through  analyzing  existing  and  deployed  systems.  The  Product  Line 
Software  Engineering,  Domain-Specific  Software  Architecture  (PuLSE-DSSA)  [3]  is 
a  process  for  creating  reference  architectures  in  an  iterative  fashion.  PuLSE-DSSA 
still  depends  on  instantiated  architectures.  Architecture  Structure  Description  Language 
(ASDL)  also  depends  on  existing  systems  to  find  commonalities  to  abstract  a  reference 
architecture.  This  process  is  does  not  directly  aid  in  constructing  new  agent  frameworks. 

Reference  architectures  for  agent-based  systems  has  been  studied  to  a  limited  extent. 
The  FIPA  Abstract  Architecture  Specification8  discusses  agent  system  architecture  in  an 
effort  to  promote  interoperability  and  reusability.  FIPA  provides  a  generic  view  on  agent 
systems  and  describes  how  specific  functionality  should  interact.  FIPA  provides  low- 
level  details  such  as  mechanisms  for  how  agents  perform  service  look-ups.  The  ASRA 
also  focuses  on  identifying  architectural  paradigms  and  patterns  in  agent  frameworks 
but  focuses  on  the  higher  level,  implementation-agnostic  interactions. 

Weyns  and  Holvoet  [12]  developed  a  Reference  Architecture  for  Situated  Multia¬ 
gent  Systems.  This  reference  architecture  focuses  on  the  agent  operating  in  an  appli¬ 
cation  environment.  This  architecture  was  developed  through  an  interative  process  of 
analysis  and  validation  studying  different  agent-based  systems.  In  their  reference  archi¬ 
tecture,  the  authors  constructed  multiple  documents  from  different  views:  the  module 
decomposition,  the  shared  data,  and  the  communicating  processes  views.  This  refer¬ 
ence  architecture  approach  focuses  on  the  agent  in  the  environment  whereas  the  ASRA 
address  the  infrastructure  of  the  environment. 


6  Conclusion  and  Future  Work 


The  Agent  Systems  Reference  Architecture  (ASRA)  is  an  ongoing  effort  to  create  a 
reference  architecture  for  agent-based  systems.  The  primary  contribution  of  this  work  is 
the  serial  process  for  creating  a  reference  architecture  for  an  agent  systems.  This  process 
begins  with  functional  concepts  defined  by  the  ASRM  and  serially  applies  dynamic  and 
static  software  analysis  of  agent  framework  implementations.  The  resulting  architecture 
is  a  set  of  architectural  views  depicting  relationships  and  structural  qualities  among 
instantiated  functional  components. 

In  future  work,  we  will  apply  this  process  on  the  rest  of  the  ASRM  functional  con¬ 
cepts  to  present  a  full  architecture  for  agent  frameworks.  Moreover,  we  intend  to  extend 
this  process  to  include  a  Deployment  view  of  agent  systems.  The  Deployment  view 
presents  the  architecture  of  an  agent  system  as  it  would  be  situated  in  the  physical  en¬ 
vironment.  Addressing  how  conceptual  components  of  an  agent  system  is  beneficial  to 
agent  system  architects,  developers,  and  system  integrators  in  identifying  real-world  is¬ 
sues  in  system  engineering.  Furthermore,  we  intend  to  address  the  paradigms  of  how 
agent  systems  interoperate  with  external  systems  (e.g.  agents  integrated  with  web  ser¬ 
vices). 


8  http : //www . f ipa. org/ specs/f ipaOOOOl 
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